\chapter{Solutions}
Following the guidelines \textit{fetching, distribution} and \textit{processing} (FDP), suggested  in the system proposal, this chapter concentrates on implementation specific details.

\begin{figure}[ht]
		\begin{center}
	    	\includegraphics[width=12.35cm]{graphics/architecture}
			\caption[Overview FDP process]{Overview FDP processes.}
			\label{Overview FDP process}
		\end{center}
\end{figure}

Reflecting the FDP process, the Cell Supplier firstly records the cell information, as visualised in figure \ref{Overview FDP process}. If the recording is completed, the Cell Supplier will send the Handovers XML-Schema instance file to the Hybrid MPC. The MPC firstly will validate and secondly import the cell information. Then the LT Provider will trigger the (re)calculation of the measurement figures (centroid, CoG). If the reverse engineering of the PLMN's cell structure is successful, the LT Provider offers an interface for positioning. Depending of the Position Request (direct or indirect), the Mobile User's LBS client sends the current cell information either to the LBS Application Server (indirect) or directly to the LT Provider's MPC. The MPC responses the approximate GPS position calculated for the cell where the Mobile User resides.

This scenario is considered in the development of the prototype. The coming sections firstly presents the \textit{fetching} process. After that it showcases the development of a hybrid MPC. This section includes the \textit{processing} aspects. Indeed, for  making the \textit{distribution} of cell information possible, the LT provider has to pay attention to XML-Schemas in order to import cell information. Finally the chapter shortly introduces a programme for the visualisation of cells, cell borders and measurement figures (centroid, CoG).

\section{CellFetcher}
Enabling reverse engineering of PLMNs the recording of the networks cell structure is  initially required. This section presents a solution concerning this matter. First of all it shows the use case for the recording process in a technical view. After that the system environment section outlines the requirements and leads over to the section about  implementation.

\subsection{Use case Fetching Cell Information}
The objective of this use case is to find out the handovers' GPS position of PLMNs. This use case shows  the \textit{basic approach} of fetching cell information, presented in the previous chapter.  The output generated are Handovers \textit{XML-Schema instance} files defined in appendix A.

\subsubsection{Primary Actor}
\textit{Mobile User} who has a programme on its MT which is able to deliver valid cell information to LT providers. This actor is defined as the \textit{Cell Supplier}.

\newpage
\subsubsection{Stakeholders and Interest}
\begin{itemize}
  \item \textit{Cell Supplier}\\
  Wants an 'easy to use' programme on the MT which records cell information. Is interested in simple \textit{User Interface} (UI) to pair the BT GPS mouse and as well to start the fetching process. Expects from the programme that the fetched cell information and GPS position are correct to distribute the information to LT providers without any concerns. 
  \item \textit{LT Provider}\\
  Wants accurate, structured and valid cell information (handovers' GPS position), which can be merged by back-end systems because mobile user position determination is based on these data.
  \item \textit{LBS User}\\
  Wants as good as possible, error-free position determination with minimal effort.
  \item \textit{Mobile Operator}\\
  Is interested in the deployment of LBSs. If loosely coupled, range-free LBSs are cost-effective and highly used, more income will be generated because LBS users use their air interfaces to connect to LBS application servers.
\end{itemize}

\subsubsection{Preconditions}
Cell supplier has installed '\textit{CellFetcher}' programme, and he or she has already proven that the programme works correctly. This means that the phone provides:
\begin{itemize}
  \item Functionality to connect to the BT GPS mouse
  \item Functionality for fetching cell information
  \item Functionality for observing field strength
  \item Memory for storing cell information
\end{itemize}

Cell supplier has already started the CellFetcher programme, and has a clear view to the sky in order to receive valid GPS information. PLMN service (e.g. GSM service) need not to exist when starting the CellFetcher programme.

\subsubsection{Postcondition}
Cell information were stored in a file on the MT's memory, and are valid and structured. Cell supplier quit the CellFetcher programme.

\subsubsection{Success Scenario}
\begin{enumerate}
  \item Cell supplier chooses on the UI of the CellFetcher programme 'GPS connect' to connect to BT GPS device.
  \item Programme starts \textit{BT Service Device Discovery} (SDD), pairs with the BT GPS Mouse, and receives continually GPS positions visualised on the MT's screen.
  \item Cell supplier checks whether the GPS position on the screen is changed when moving. This is important to prevent incorrect GPS positions because of a possible \textit{warm start} of BT GPS mouse.
  \item Cell supplier chooses on the UI of the CellFetcher programme 'Start fetching'.
  \item Cell supplier restarts moving (walking, cruising, etc.). 
  \item Programme requests the \textit{current cell information} \footnote{The cell information entity consists of cell-id, AC, MCC, MCC} and the \textit{current field strength}, and stores \textit{current cell information} and \textit{current field strength} as \textit{origin cell information} and \textit{origin field strength}.
  \item Programme starts observing the field strength information by registering the asynchronous \textit{field strength changed} event.
  \item Programme starts observing the cell information by registering the asynchronous \textit{handover occurred} event.
  \item Programme is notified by the \textit{SignalStrength} API because field strength changed.
  \item Programme request the \textit{current field strength}, stores it as \textit{origin field strength}, and starts observing the field strength information by registering the asynchronous \textit{field strength changed} event.\\
  		\textit{Programme repeats step 9-10 until handover occurs.}
  \item Programme is notified by the \textit{CellInfo} API because handover occurred.
  \item Programme takes the \textit{current cell information}, queries synchronously the \textit{current field strength} from the \textit{SignalStrength} API and stores the former data as \textit{destination cell information} and the second as \textit{destination field strength}.
  \item Programme queries the \textit{current GPS position} from the BT GPS device.
  \item Programme stores the \textit{origin cell information}, \textit{origin field strength}, the \textit{destination cell information}, the \textit{destination field strength} and the \textit{current GPS position} in a file on the MT's memory.
  \item Programme copies \textit{destination cell information} into \textit{origin cell information} to know the \textit{origin cell information} when a further handover takes place.\\
  		\textit{Programme repeats from step 8 until cell supplier chooses 'Stop fetching'.}
  \item Cell supplier reaches the destination of the route and chooses 'Stop fetching' on the UI.
  \item Programme disconnects from \textit{field strength occurred} event and from \textit{handover occurred} event.
  \item Cell supplier chooses 'GPS disconnect' on the UI in order to disconnect from the BT GPS mouse.
\end{enumerate}

\subsubsection{Special Requirements}
If a handover occurs, the current field strength will be queried synchronously instead of asynchronously in order to verify that the data are valid (step 12).

\subsection{System Environment}
This programme is based on \textit{Symbian OS Series 60 6.1}. For getting GPS positions a BT GPS mouse, compliant to NMEA \citep{NMEA2006}, is used. The programme was tested on a \textit{Nokia N70} in conjunction with an \textit{ADAPT AD-300} BT GPS receiver.

Symbian's current version 9.0 offers its own security programme, \textit{Symbian Signed}, which is meant to provide legal products with a digital signature of Symbian \citep{Gutz2005}. Using the CellFetcher programme on Symbian OS from release 9.0 upwards requires a Symbian digital signature in order to be able to obtain cell information.

\subsection{Implementation}
This programme has been implemented, as conceived in the preceding use case. The Series 60 \textit{Software Development KIT} (SDK) does not officially support access to cell information, but the necessary libraries (gsmbas.lib and etel.lib) are available, and the older \textit{Communicator 9200 SDK} (at least version 0.9) contains the essential \textit{Header} files (etel.h and etelbgsm.h) \citep{Raento2004}. By means of these libraries the cell information have been fetched. Furthermore some simple BT GPS connection classes are required to get to know the position in case of a handover. Concerning this matter a few classes from \citet{Lukic2003} have been adapted and 'refactored'.

Symbian OS usually proposes a multi-layered application \textit{design}. Even tough the resources on mobile phones are limited this gives the possibility to separate \textit{business logic} from \textit{Graphical User Interface} (GUI) and \textit{persistence}.

\begin{figure}[ht]
		\begin{center}
	    	\includegraphics[trim=2cm 6.7cm 2cm 6.9cm, width=14.5cm, clip=true]{graphics/cellFetcherClassModel}
			\caption[Class model CellFetcher]{Class model CellFetcher.}
			\label{Class model CellFetcher}
		\end{center}
\end{figure}

\newpage
\noindent
As seen in a simplified CellFetcher class model \ref{Class model CellFetcher}, the usual architecture of Symbian GUI applications consists of:
\begin{itemize}
  \item \textit{Application View} (\texttt{CCellFetcherContainer})\\
  The root GUI control, which implements the main window and acts as a container for other application controls.
  \item \textit{Application UI} (\texttt{CCellFetcherAppUi})\\
  This class creates the Application View, and fulfils the tasks of an usual controller within a \textit{Model View Controller} (MVC) design \citep{Szyperski2002}.
  \item \textit{Application Document} (\texttt{CCellFetcherDocument})\\
  This class instantiates the Application UI and handles persistence aspects like \textit{serialisation} of application data.
  \item \textit{Application} (\texttt{CCellFetcherApp})\\
  Is the usual entry point providing an \textit{Unique Identifier} (UID), which is required for each application. Furthermore this class is responsible for the creation of the Application Document object.
\end{itemize}

The \texttt{CellFetcherAppUi} (controller) class is responsible for handling the data delivered by \texttt{GPSReceiver}, \texttt{SignalStrengthReceiver} and \texttt{CelInfoReceiver}. The \textit{Observer}  \textit{Design Pattern} can be applied for getting asynchronous events \citep{Gamma1997}. Thereby the controller object is notified in case of any changes regarding GPS position, signal strength or cell information. Worth mentioning thereby is, that the controller manages two \texttt{CellInfo} and two \texttt{SignalStrength} objects. This is because the origin and the destination information have to be known when a handover takes place. Each of these classes (\texttt{CellInfo}, \texttt{GpsPosition}, \texttt{SignalStrength}) can serialise its current state as an XML stream, which is executed when handover data are written into a file.

As seen in class model \ref{Class model CellFetcher}, the classes \texttt{SignalStrength} and \texttt{CellInfoReceiver} are derived from the Symbian specific class \textit{CActive}. This is the base class for Symbian's \textit{Active Objects} thread library. Many of the Symbian OS API functions are asynchronous functions, and using them provides parallel execution within an application. Relating to \citet[p. 235]{Babin2006}, Active Objects are used to invoke an asynchronous function, and to handle the completion of the asynchronous function via a callback. In this connection they are used to find out when either network or field strength information changes. Further information about Active Objects can be looked up in Developing Software for Symbian OS \citet{Babin2006}.

Figure \ref{Sequence diagram CellFetcher} presents the sequence of commands when the user presses ``Start fetching''. The \texttt{Start()} method of the \texttt{SignalStrengthReceiver} and of the \texttt{CellInfoReceiver} are called. These two objects are responsible for observing either the field (signal) strength or the network (cell) information. The asynchronous calls \texttt{SignalStrengthNotification()} and \texttt{NotifyChangeOfCurrentNetwork()} and the further \texttt{SetActive()} call in both cases notify the \textit{Active Scheduler} to check permanently for  changes regarding these parameters. Once either the field strength or cell information changes the value of the \texttt{TRequestStatus iStatus}, named as the \textit{Request Semaphore}, is set to \texttt{KErrNone} by the active scheduler, and the \texttt{RunL()} callback-method of the active object that the event belongs, is invoked by the active scheduler. The \texttt{RunL()} method notifies changes to the controller (\texttt{iAppUi}). Finally the GUI (\texttt{iAppContainer}) is informed by the controller about the state change to visualise the new information on the screen.

\begin{figure}
		\begin{center}
	    	\includegraphics[trim=2cm 1.5cm 2cm 1.5cm, angle=90, width=14cm, clip=true]{graphics/cellFetcherSequenceDiagram}
			\caption[Sequence diagram CellFetcher]{Sequence Diagram CellFetcher.}
			\label{Sequence diagram CellFetcher}
		\end{center}
\end{figure}

The active scheduler's event loop, along with its active object's \texttt{RunL()} invocations, occur in the same thread, also  known as \textit{Non-Preemptive Multitasking}. This means that one active object cannot start running while another one's \texttt{RunL()} method is in progress. Therefore the programme counter should not spend much time inside active object's \texttt{RunL()} function, since it prevents all other active objects in the same thread from running. 

Active objects relieves from \textit{polling}. Busy loops cause a lot of \textit{context switches} in the kernel, and are wasteful \citep[p. 236]{Babin2006}. Hence the energy consumption increases, and therefore the MT's usability is reduced. Symbian OS would provide also APIs for \textit{Synchronisation}, \textit{Inter-Thread Communication}, \textit{Shared Memory Regions}, \textit{Semaphores}, \textit{Mutexes} and \textit{Critical Sections} \citep[chap. 7]{Babin2006}, if active objects did not meet the requirements.

Finally as seen in figure \ref{Sequence diagram CellFetcher}, the controller takes the origin and destination network information in conjunction with the GPS position and stores this data in a file by calling \texttt{WriteDataIntoFile()} of the \texttt{iAppDocument} object. Due to simplicity reasons the \texttt{BTGpsReceiver} is omitted in this model. This object provides like the \texttt{SignalStrengthReceiver} and the \texttt{CellInfoReceiver} a listener interface for receiving GPS positions.

\newpage
\noindent
The Handovers XML-Schema, proposed in appendix A, has been considered for structuring the output file \ref{handoversXMLSchemaInstance} as follows.

\begin{lstlisting}[label=handoversXMLSchemaInstance, caption={Overview Handovers XML-Schema instance.}]
<handovers>
 <handover date="2006-08-02T20:18:16.14">
  <origin>
   <cell id="1532318" areacode="9000" mcc="232" mnc="10" longname="3 AT" shortname="3" status="2"/>
   <signalstrength>83</signalstrength>
  </origin>
  <destination>
   <cell id="1542618" areacode="9000" mcc="232" mnc="10" longname="3 AT" shortname="3" status="2"/>
   <signalstrength>83</signalstrength>
  </destination>
  <gps>
   <longitude>9.74576000</longitude>
   <latitude>47.41650000</latitude>
   <status>1</status>
   <utctime>18:18:50.934</utctime>
   <speedInCmH>0.000</speedInCmH>
   <altitude>539.7</altitude>
   <altitudeunits>m</altitudeunits>
   <geoidseparation>48.1</geoidseparation>
   <geoidseparationunits>m</geoidseparationunits>
  </gps>
 </handover>
</handovers>
\end{lstlisting}

\noindent
Further implementation details about this programme can be looked up on the companion CD.

\section{Hybrid Mobile Positioning Center}
Providing a positioning component requires the \textit{processing} of recorded cell information. This section presents first of all how these information can be organised in an \textit{Object Oriented} (OO) environment. After that the use cases \textit{Validate and Import} are showcased in combination. The aspects of \textit{cell information distribution}, proposed in the system proposal (chap. 4), are kept in mind in this regards. Showing the \textit{Position Request} in addition, this section finally includes two proposals about the way of offering third-party interfaces.

\subsection{System Environment}
This prototype is based on Java 5.0 in conjunction with Hibernate 3.1.1 \citep{Hibernate2006}. \citet{MySQL2006} is used as \textit{Database Management System} (DBMS). It was tested on \textit{Windows XP} and \textit{Unix} (\textit{SUSE Linux 10.0}, \textit{Mac OS X 10.4.7}) systems offering Java 5.0. Regarding MySQL, the programme requires version 4.1 upwards. Anyway, other Hibernate compliant DBMSs can be used either.

\subsection{Implementation}
The architecture  of this prototype is divided into three layers. On top a controller layer is responsible for handling user requests. User request can either be data requests to validate, import and merge new cell information or positioning requests. In the middle is the management layer responsible for implementing the business logic. One part of this layer are business objects. Furthermore this layer contains a few management objects protecting the model from the upper environment, and for the handling of object delegation between controller and domain model. Particularly for using this class composition in different environments the persistence layer is introduced to verify that business objects are independent of the underlying storage mechanism. In fact a persistence facade based on Hibernate, an \textit{Object-Relational-Mapping} (ORM) service, controls the access to the database.

Relating to \citet[p. 540]{Larman2002}, one key idea of ORM services is to know the \textit{transaction state} of an object. In fact Hibernate knows the transaction state of every business object. Depending on the transaction state Hibernate will update a database record, if the object is \textit{dirty} or will create a new one in case of a \textit{new} object.

Providing loosely coupled, range-free LBSs requires the parsing of XML-structured cell information. This is done by means of the \textit{Simple API for XML} (SAX). The resulting output of this step is the transition from XML based data into an OO environment. Class model \ref{Class model hybrid MPC} shows how the elements and attributes of the Handovers XML schema-instance file are mapped to Java classes.

As seen in the model, most of the implemented classes have not yet implemented any business logic. However, the \texttt{Cell} class is responsible for calculating the crucial measures (centroid and CoG) in order to provide positioning. This class manages a collection of cell borders. Each cell border knows its specific position with aid of the \texttt{GpsPosition} class.

This model incorporates the semantics of handovers by means of the \texttt{Handover} class. This class provides in succession a possibility to check whether a handover always takes place at a specific position. Moreover, the \texttt{Sample} class can be used to record cell information at specific positions. Another field of application of this class is to check whether the field strength varies at a specific position. The \texttt{SampleType} class permits static or dynamic definition of a sample. A static sample is recorded by the Cell Supplier manually at a particular position whereas dynamic samples are created when moving based on the velocity (e.g. make a sample every 100 meters).

Classes like \texttt{Country}, \texttt{Network}, \texttt{Area} provide information about the coverage (e.g. bounding coordinate of an area) and statistics (e.g. number of cells in network) besides its primary purpose of identifying cells.

\begin{figure}[ht]
		\begin{center}
	    	\includegraphics[trim=1cm 11cm 1cm 1cm, width=14cm, clip=true]{graphics/mpcClassModel}
			\caption[Class model hybrid MPC]{Overview business objects.}
			\label{Class model hybrid MPC}
		\end{center}
\end{figure}

Reflecting the overall architecture of the prototype, firstly the validation and import of recorded cell information, and secondly the position request is presented.

\subsection{Validation and Import of Cell Information}
Actor Cell Supplier calls firstly \texttt{validate()}, as visualised in \ref{Sequence diagram MPC Import cell information}. This call is delegated to the \texttt{HandoverManager} instance. Mentionable here is that the logic of the validation is implemented in the management object and not in the controller instance. The validation itself is done by checking the file's structure with the Handovers XML-Schema. If the file is schema-valid and well-formed the \texttt{parse()} method initialises new \texttt{Handover} objects and returns the number of handovers parsed.

\begin{figure}[ht]
		\begin{center}
	    	\includegraphics[trim=1cm 14cm 1cm 0.5cm, width=14cm, clip=true]{graphics/mpcSequenceDiagramImport}
			\caption[Sequence diagram MPC Import cell information]{Import of XML-structured cell information.}
			\label{Sequence diagram MPC Import cell information}
		\end{center}
\end{figure}

Finally by calling \texttt{saveParsedHandovers()}, the management objects will loop over the parsed handovers, and store each handover in the database, if this specific record does not exist. As illustrated in figure \ref{Sequence diagram MPC Import cell information} the \texttt{PersistenceFacade} takes the parsed handovers. In order to pass on the business object to the according broker, the Java \textit{Reflection} API is used. For every class a corresponding \texttt{broker} object exists which is administered by the \texttt{BrokerFactory} class.

\subsection{Position Request}
Actor Mobile User calls \texttt{getPosition()} by sending his or her current cell information to the LT provider interface. The LT provider queries the \texttt{cell}, the Mobile User is requesting. If the \texttt{cell} is registered in the system, the approximate position (e.g. centroid or CoG) will be returned by the system as approximate mobile user position.

\begin{figure}[ht]
		\begin{center}
	    	\includegraphics[trim=1cm 21cm 1cm 1cm, width=14cm, clip=true]{graphics/mpcSequenceDiagramRequest}
			\caption[Sequence diagram MPC Positioning Request]{Handling of Position Request.}
			\label{Sequence diagram MPC Positioning Request}
		\end{center}
\end{figure}

This process requires enhanced \textit{Caching} capabilities because of the frequency of occurrence. Accessing the persistence layer in every request is not sensible, as proposed in diagram \ref{Sequence diagram MPC Positioning Request}. In fact the \textit{PositionRequestManager} is designated concerning this task.

\subsection{Third-Party Interfaces}
Considering the Positioning Request use case, the request originates on the MT of the Mobile User. The request has to be forwarded by the mobile operator's air interface to the LT provider's interface. This can be implemented either by a \textit{Remote Procedure Call} mechanism or by an application level protocol such as MLP.

Regarding \textit{Software Engineering} aspects the goal is to provide simple, non-proprietary and reusable interfaces. Of course there might exist a lot of conceivable possibilities concerning the technologies used. However, one of two prestigious solutions is using SOAP. One advantage of SOAP is its platform independence because SOAP wrappers exist for almost any technology.

Another solution is a \textit{Java Message Service} (JMS) based approach which does not couple the LBS and LT providers as tightly as SOAP does. JMS permits sending plain text \citep[p. 320]{Szyperski2002}. This fact gives the potential to define also an XML-type based protocol quite similar to the LIF's MLP protocol. Furthermore depending on the simplicity of such a protocol definition, MTs probably could directly consult the LT provider to find out the position. This scenario is interesting for fat-client mobile applications which hosts their own personal map data on the MT, and only get to know their position.

One example thereby is a traffic information application which has an own motorway map on the MT. This application then interacts directly by means of an XML based protocol with the LT provider to determine the approximate position. Furthermore it utilises radio \textit{Traffic Message Channel} (TMC) signals for finding out traffic information depending on the user's position. Further information about TMC can be looked up in \citet{TMC2006}.

\subsection{Discussion and Limitations}
The main objective of this prototype is providing reusable classes for ongoing development. The layered approach gives the possibility to build upon the controller a specific presentation layer. Any kind of RPC technologies can be integrated by replacing the controller layer. Furthermore the persistence layer permit the change of the persistence mechanism.

This prototype only implements the business logic as presented. Any third-party interfaces for LBS providers or mobile users have not been implemented. Nevertheless this prototype is reusable because of its class design, and offers the possibility to integrate it into any kind of Java based application.

Providing QoS for LBS providers and mobile users requires further information in the position response which has not yet been considered. Ericsson informs about accuracy by means of two specific attributes indicating whether the accuracy is high, medium or low \citep{Ericsson2003}. Particularly in the context of such an approach the measured \textbf{diameter} of a cell can be included. The cell size has an impact on accuracy. Hence including it as QoS parameter gives other parties the chance to make further decisions on it.

Another aspect not considered so far is the altitude dimension. Technically the business logic provides the information because any GPS positions stored contains information about the altitude. However, knowing the centroid or CoG the corresponding altitude parameter has to be requested from a \textit{Geographic Information System} (GIS), and cannot approximately calculated by means of cell borders. Only this way verifies that the provided altitude matches the horizontal position.

\noindent
This prototype was used in conjunction with the calculation of the test results. Further information concerning this prototype can be looked up on the companion CD.

\section{Cell Information Visualisations}
This programme has served as utility in the implementation process to verify the concepts.

\subsection{System Environment}
This programme is written in C\# based on \textit{.Net 2005} and \textit{Map}\&\textit{Guide mapserver 4.5}, and tested on Windows XP.

\subsection{Implementation}
Reflecting some products (Map\&Guide, MS MapPoint and Destinator) Map\&Guide mapserver 4.5 has been chosen because of the good quality of the available GIS maps. Furthermore, mapserver 4.5 provides an powerful interface for the visualisation of  custom objects like \textit{Point of Interests} (POIs). This prototype abstracts the \textit{MapEditor} and \textit{AddressMonitor} \textit{Component Object Model} (COM) interface.

\noindent
This programme outputs maps, as illustrated in figure 5.7.

\begin{figure}[ht]
		\begin{left}
	    	\includegraphics[width=8cm]{graphics/map2109}
			\caption[GIS visualisation example]{Visualisation of cell information\\ (Cell-Id: 2109; AC: 11902; MNC:1; MCC:232; provider: A1).}
			\label{GIS visualisation example}
		\end{left}
\end{figure}

Figure 5.7 is used for checking whether the algorithm for ordering cell borders is correct. As seen in the figure, the cell borders (red dots with numbers) are ordered counter-clockwise. Another approach for solving this is using a GIS WS.

\section{Summary}
This chapter reflects some concepts applied in the solutions. First of all it presents a tool for fetching cell information. Regarding this matter, Symbian's active objects thread library is presented. 

Showing snippets of an XML-Schema instance handover file leads over to the presentation of the hybrid MPC prototype. The overview of business objects gives further insight into the development. Two sequence diagrams presents the overall system architecture. Finally this chapter informs about the way how cell information are visualised.
